Done. Here's what I changed:

1. Created tests/PHPStan/Rules/Methods/data/bug-14549-bis.php — a separate test file for CallMethodsRuleTest with methods accepting array<int>, array{string, string}, array{object|string, string}, and array{object|string, string, string}, called from both callable-array and callable&array typed parameters.

2. Removed call-related methods from bug-14549.php — the call(), doCallWithCallableArray(), and doCallWithCallableAndArray() methods that were only used by CallMethodsRuleTest are now in the separate file.

3. Updated CallMethodsRuleTest — now uses bug-14549-bis.php and verifies the constant array test cases:

   • array{string, string} → Error (callable-array has object at index 0)
   • array{object|string, string} → No error (matches callable-array shape)
   • array{object|string, string, string} → Error (callable-array has 2 elements, not 3)

4. Updated MissingMethodParameterTypehintRuleTest — removed expectations for methods that moved to the new file.

I processed this review but have nothing to report.

Done. Here's a summary of what I changed:

The problem: The reviewer pointed out that the PR's approach of special-casing callable&array in IntersectionType::isAcceptedBy() was too narrow. The same issue exists for other intersection types like array<mixed>&hasOffsetValue(1,1) — they were incorrectly accepted by array<string> because MixedType::isAcceptedBy() always returns Yes, and lazyMaxMin short-circuits on that.

Root cause: MixedType implements CompoundType and its isAcceptedBy() always returns Yes (since mixed is a supertype of everything). When lazyMaxMin iterates intersection components individually, it short-circuits on the first Yes from array<mixed>, ignoring that other components (like hasOffsetValue(1,1) or callable) constrain the intersection in ways that make it incompatible.

The fix: Replace the callable&array-specific narrowing with a general guard: after lazyMaxMin produces a Yes result, verify it with $acceptingType->isSuperTypeOf($this). The isSuperTypeOf chain (which goes through IntersectionType::isSubTypeOf) correctly considers all components together and returns No when the intersection as a whole is not a subtype. If isSuperTypeOf says No, we override the false Yes.

This approach:

• Fixes the original callable&array vs array<int> case
• Also fixes the reviewer's array<mixed>&hasOffsetValue(1,1) vs array<string> case
• Preserves $strictTypes coercion behavior (since accepts is still the primary check)
• Preserves error reasons from accepts (the isSuperTypeOf guard only overrides on definitive No)
• All 11,971 tests pass and make phpstan reports no errors

This seems to work but I wonder if I and the bot are not making a mistake by confusing accepts and isSuperTypeOf...

And there is multiple integration test failure I'll need to check

I'll need to take more time on it, just wanted to know if it's inspire you @staabm ?
Maybe you see a better direction for this PR.

to fix this one, I would investigate why https://phpstan.org/r/d89df38c-c43c-49fe-bcdc-03a29f285690 reports

Parameter #1 $task of method MondayMorning::call() expects array, array given.

and than would try to check how the relevant logic can be applied to
https://phpstan.org/r/d6ef05eb-6a35-4621-a996-d6558786e70f

saying that and looking at

looking deeper my feeling is the problem needs a fix in IntersectionType->isAcceptedBy(), likely using something like if ($this->isCallable()->yes() && $this->isArray()->yes()) {

another thing which could work is

diff --git a/src/Type/ArrayType.php b/src/Type/ArrayType.php
index 777343626..124405a14 100644
--- a/src/Type/ArrayType.php
+++ b/src/Type/ArrayType.php
@@ -112,11 +112,9 @@ class ArrayType implements Type
                        }
 
                        return $result;
-               }
-
-               if ($type instanceof ArrayType) {
-                       return $this->getItemType()->accepts($type->getItemType(), $strictTypes)
-                               ->and($this->keyType->accepts($type->keyType, $strictTypes));
+               } else if ($type->isArray()->yes()) {
+                       return $this->getIterableValueType()->accepts($type->getIterableValueType(), $strictTypes)
+                               ->and($this->keyType->accepts($type->getIterableKeyType(), $strictTypes));
                }
 
                return AcceptsResult::createNo();

It's not 100% related to callable because the issue exist with HasOffsetType and HasOffsetValueType too

Array of string
shouldnt accept array&hasOffsetValue<3, int>

For instance

It's not 100% related to callable because the issue exist with HasOffsetType and HasOffsetValueType too

Array of string shouldnt accept array&hasOffsetValue<3, int>

ok, than its definitly in IntersectionType (which is the type all your examples have in common)

Done. Here's a summary of what I did:

Added IntersectionTypeTest cases for isAcceptedBy and isSubTypeOf as requested by the reviewer:

1. testIsAcceptedBy (new data provider + test method) with 9 test cases:

   • array&callable isAcceptedBy array → Yes (success)
   • array&callable isAcceptedBy array<int> → No (failure — the isSuperTypeOf guard catches this)
   • array&callable isAcceptedBy array{object|string, string} → Maybe (success)
   • array&callable isAcceptedBy array{string, string} → Maybe (failure)
   • array&hasOffsetValue(3,int) isAcceptedBy array → Yes (success)
   • array&hasOffsetValue(3,int) isAcceptedBy array<string> → No (failure — the guard catches this)
   • array&hasOffsetValue(3,int) isAcceptedBy array<int> → Yes (success, matching value type)
   • array&hasOffsetValue(0,int) isAcceptedBy array{int, int} → Maybe (success)
   • array&hasOffsetValue(3,int) isAcceptedBy array{string, string} → Maybe (failure)

2. testIsSubTypeOf additions (5 cases) answering the reviewer's question about whether isSubTypeOf has the same issue:

   • array&callable isSubTypeOf array → Yes
   • array&callable isSubTypeOf array<int> → No (correct!)
   • array&hasOffsetValue(3,int) isSubTypeOf array → Yes
   • array&hasOffsetValue(3,int) isSubTypeOf array<int> → Maybe
   • array&hasOffsetValue(3,int) isSubTypeOf array<string> → No (correct!)

Answer to the reviewer's question: The issue does NOT exist in isSubTypeOf. Unlike isAcceptedBy (which uses lazyMaxMin and can short-circuit on Yes from MixedType::accepts), isSubTypeOf uses lazyMaxMin on $otherType->isSuperTypeOf($innerType) which correctly produces No results when types are incompatible (e.g., array<int>->isSuperTypeOf(CallableType) returns Maybe, not Yes, so it never short-circuits incorrectly).

Pushed. Here's my analysis of the E2E errors and what I changed:

Analysis of E2E errors

Error 1 (BeberleiAssert): non-empty-array<Closure> vs array<string, callable(...)> — REGRESSION from the PR. The isSuperTypeOf guard was too strict: string->isSuperTypeOf(mixed) returns no (mixed is broader than string), but string->accepts(mixed) correctly returns yes (mixed could be string). The new approach fixes this.

Errors 2-4 (Nette ContainerLoader, Shopware, Nette ServiceDefinition) — Likely NOT caused by this PR. None of these types appear to involve IntersectionType in a way that would trigger the guard:

• Error 2: Closure(Compiler): void vs callable(Compiler): (string|null) — plain ClosureType, not an intersection
• Error 3: array vs array<string, mixed> — plain ArrayType, not an intersection
• Error 4: string vs class-string|null — plain StringType, not an intersection

What changed

Replaced the blanket isSuperTypeOf guard with a targeted re-check: when lazyMaxMin short-circuits on yes (from ArrayType(mixed,mixed) being accepted by any array type due to MixedType::isAcceptedBy), re-check the non-array intersection components that were skipped. If any returns no, override the result. This correctly catches callable, HasOffsetValueType, and other accessory type constraints without the false positives from mixing accepts/isSuperTypeOf semantics.

Pushed. Here's what I changed:

Removed from IntersectionType::isAcceptedBy() (lines 307-317): The guard block that re-checked non-array components when the result was Yes and the accepting type was an array.

Removed from IntersectionTypeTest: All dataIsAcceptedBy/testIsAcceptedBy test cases (9 cases) and the isSubTypeOf additions (5 cases) — 159 lines total.

Added to ArrayType::accepts(): After the CompoundType delegation to isAcceptedBy(), a guard that catches false Yes results from lazyMaxMin short-circuiting on array<mixed>. When the result is Yes and the type is an IntersectionType that is an array, each non-array component is re-checked individually. If any returns No (e.g., array<int>::accepts(callable) → No), the No is returned instead.

Updated baseline: instanceof IntersectionType count in ArrayType.php from 1 to 2.

This approach preserves the existing isAcceptedBy delegation (avoiding regressions with normal array intersections like non-empty-array<int, list<int>>) while catching the specific bug where array<mixed> in an intersection causes lazyMaxMin to short-circuit incorrectly. All 11,994 tests pass and make phpstan reports no errors.

Integration failure are valid to me ; for instance

Method Shopware\Core\Kernel::getKernelParameters() should return array<string, array<string, mixed>|bool|float|int|string|UnitEnum|null> but returns array<string, array|bool|float|int|string|UnitEnum|null>.  

'kernel.supported_api_versions' => [2, 3, 4], doest not respect array<string, mixed>